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Parallels  In  Computer-Aided  Design  Framework  and 
Software  Development  Environment  Efforts 


Abstract:  This  paper  is  an  attempt  to  raise  awareness  about  the  simiiarities 
between  the  efforts  of  the  software  development  environment  (SDE) 
community  and  the  electronic  computer-aided  design  (CAD)  framework 
community.  Apparently,  SDE  and  CAD  engineers  are  not  aware  of  what  is 
happening  in  each  other's  fields,  yet  cross-pollenization  of  efforts  would  assist 
progress.  Both  communities  are  addressing  the  same  probiems  of  providing 
configuration  management  (CM),  tool  integration,  and  process  management 
support  in  their  environment.  Each  community  can  benefit  from  the  other  since 
both  have  simiiar  needs  and  have  found,  and  are  finding,  similar  solutions,  it  is 
particulariy  useful  to  consider  coliaborative  efforts  as  both  communities  are 
evoiving  towards  standardization. 


1  Introduction 

The  SDE  community  is  focusing  on  the  problems  of  CM,  third-party  tooi  integration,  and  pro¬ 
cess  modelling,  as  is  the  CAD  community.  Commercially,  this  can  be  seen  from  the  plethora 
of  third-party  toois  for  CM,  computer-aided  software  engineering  (CASE)  tools,  third-party  de¬ 
sign  kits,  and  tooi  and  design  management  frameworks.  Also,  books  about  software  engineer¬ 
ing  environments  (Long  91]  and  electronic  design  automation  frameworks  have  been 
appearing  [Rammig  91],  as  well  as  articles  about  standardization  efforts  in  reference  modeis 
for  environments  [Brown92],  tool  integration  [Zarrella  90],  and  agreement  upon  a  universai  de¬ 
sign  automation  framework,  such  as  the  CAD  Framework  Initiative  (CFi)  [Malasky  91].  Thus, 
from  a  software  engineering  point  of  view,  it  is  dear  that  both  communities  are  currentiy  tack¬ 
ling  similar  solutions  for  supporting  automated  CM  and  framework  technology  that  enables  in¬ 
tegration  of  third-party  tools  and  support  for  process  (task)  management.  In  particular,  CAD 
framework  vendors  have  to  address  the  needs  of  both  communities,  since  they  need  a  SDE 
in  order  to  develop  their  CAD  framework  for  their  customers. 

The  following  sections  give  an  overview  of  the  key  concepts  and  chaiienges  for  CM  support 
and  environments  in  both  communities.  A  discussion  follows  summarizing  the  similarities  and 
differences  between  the  communities,  and  the  conciusion  suggests  how  each  community 
couid  benefit  from  the  other. 
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2  State  of  Automated  CM  in  the  SDE  Community 


In  the  software  engineering  community,  the  standard  definition  of  CM  involves  four  require¬ 
ments:  identification,  control,  status  accounting,  and  audit  and  review.  The  paper  by  Dart  ex¬ 
tracts  15  CM  concepts  from  existing  SDEs  and  tools  [Dart  91].  These  concepts  indicate  that 
what  is  implemented  in  CM  systems  really  goes  beyond  that  standard  definition  into  support 
for  manufacture,  process  modeling  and  teamwork.  These  15  concepts  are: 

1 .  Repository:  captures  CM  information  and  stores  versions  of  files  as  immuta¬ 
ble  objects,  as  in  RCS  [Tichy  82]. 

2.  Distributed  component:  allows  distributed  users  to  have  access  to  a 
centralized  repository;  to  them,  the  CM  facilities  seem  to  span  the  network  of 
heterogeneous  workstations,  as  in  Sherpa  DMS  [Deitz  91]. 

3.  Context  management:  captures  in  a  domain-specific  manner  the  working 
context  for  the  user,  thereby  eliminating  the  need  for  users  to  remember  how 
they  got  to  a  particular  working  status  and  what  all  the  data  items, 
relationships,  and  tools  are  in  that  context,  as  in  Powerframe  [Johnson  89]. 

4.  Contract:  represents  a  formal  plan  for.  and  a  record  of.  a  unit  of  work  on  a 
configuration  item,  as  in  ISTAR  [Graham  88]. 

5.  Change  request:  assists  in  driving  the  process  of  change  to  configurations 
and  keeping  an  audit  trail  of  the  changes,  as  in  LIFESPAN  [Whitgift  91]. 

6.  Llfe>cycie  model:  represents  the  process  of  developing  and  maintaining 
configurations  based  on  a  predefined  life  cycle,  as  in  CCC  [Softool  87]. 

7.  Change  set:  represents  a  logical  change  to  a  product  and  a  means  of 
creating  any  version  of  a  configuration  that  is  not  necessarily  dependent  on 
the  latest  version  of  that  configuration,  as  in  ADC  [SMDS  89]. 

8.  System  modeling:  abstracts  the  notion  of  a  configuration  from  an  instance 
of  it,  and,  by  fully  describing  the  configuration,  enables  tools  to  maintain  the 
integrity  of  the  configuration,  as  in  Jasmine  [Marzullo  86]. 

9.  Subsystem:  provides  a  means  to  limit  the  effect  of  changes  and 
recompilation,  and  a  means  for  the  environment  to  check  the  validity  of 
combining  parts  of  a  system,  as  in  Rational  [Feiler  88]. 

10.Ob]ect  pool:  optimizes  the  need  for  regenerating  objects  and  maximizes  the 
sharing  of  derived  objects,  as  in  DSEE  [Leblang  85]. 

1 1  .Attribution:  permits  the  description  of  a  system  at  a  higher  level  of 
abstraction  via  its  characteristics  rather  than  in  terms  of  a  lengthy  composition 
list  of  files,  as  in  Adele  [Estublier  85]. 

12.Conslstency  maintenance:  enables  the  environment  to  identify  any 
inconsistencies  and  to  preserve  consistencies  in  creating  and  reusing 
configurations,  as  in  CMA  [Pioedereder  89]. 


CMU/SEI-92-TR-9 


3 


13.  Workspace:  provides  isolation  of  work  between  engineers  and  distinguishes 
between  a  global,  long-term  repository  for  immutable  objects  and  a  private, 
shorter-term  repository  for  mutable  objects,  as  in  shape  [Mahler  88]. 

14. Transparent  view:  gives  a  viewing  mechanism  for  a  configuration  from  the 
public  repository  with  protection  against  unauthorized  access,  as  in  SMS 
[Cohen  88]. 

15. Transaction:  synchronizes  and  coordinates  teams  of  engineers  changing 
the  same  or  different  parts  of  a  system,  as  in  NSE  [Feiler  90]. 

(Note  that  although  the  examples  for  the  concepts  distributed  component  and  context  man¬ 
agement  were  taken  from  CAD  frameworks,  variations  on  these  concepts  exist  in  some 
SDEs.) 

No  single  CM  system  provides  all  the  above  concepts,  although  a  survey  of  CM  systems  indi¬ 
cates  that  CM  systems  are  approaching  a  common  set  of  concepts  in  the  SDE  arena.  Yet 
there  is  a  lack  of  common  terminology;  no  well-understood  vocabulary  exists  for  software  en¬ 
gineers  to  discuss  CM.  Different  terms  are  meant  to  be  the  same  concept  while  similar  terms 
mean  different  concepts.  Implementations  of  the  same  concept  can  have  different  semantics. 
For  instance,  in  various  implementations  of  version  graphs,  varying  semantics  for  merging 
branches  and  different  purposes  for  branches  can  be  found  [Feiler  91].  The  lack  of  a  common 
terminology  inhibits  progress  as  there  is  no  standard  specification  or  model  for  CM. 

At  the  Software  Engineering  Institute  (SEI),  we  are  attempting  to  address  the  need  for  a  stan¬ 
dard  CM  model  by  unifying  the  above  concepts  into  a  CM  services  model.  This  model  will  be 
a  conceptual  framework  for  a  set  of  well-defined  services.  “Service”  is  meant  as  a  particular 
CM  functionality.  "Well-defined”  means  that  a  service  is  defined  in  such  a  way  that  its  seman¬ 
tics,  interface,  and  other  properties  are  understood  enough  to  be  included  in  framework  refer¬ 
ence  models  and  to  be  implemented,  albeit  with  possibly  different  mechanisms. 

The  services  in  the  model  take  into  account  the  software  engineering  marketplace’s  need  to 
apportion  and  distribute  functionality.  That  is,  CASE  tools  and  environments  provide  parts  of 
CM  solutions  and  customers  buy  these  pieces  as  building  blocks  for  their  solution  (since  no 
single  CM  system  is  a  panacea).  The  CM  solution  is  generally  spread  across  tools.  The 
services  model,  in  essence,  is  intended  to  provide  plug  in/plug  out,  “black  box”  capabilities  so 
that  over  time,  services  could  be  replaced  with  new  ones.  Examples  of  services  are  repository, 
system  modelling,  version  control,  derived  object  management,  change  management,  version 
differentiation,  and  so  on.  The  model  addresses  upward  compatibility,  since  no  single  environ¬ 
ment  will  emerge  as  the  most  popular  given  tnat  customers  have  their  existing  solution  and  no 
off-the-shelf  solution  exactly  matches  the  homegrown  solution. 

The  future  needs  for  CM  can  be  characterized  by  five  aspects:  technology,  process  orienta¬ 
tion,  management,  standardization,  and  politics.  New  technology  is  needed,  such  as  support 
for  distributed  CM  capabilities,  interoperability  between  CM  systems,  customizable  CM  sys¬ 
tems,  and  a  global  perspective  on  CM  repositories.  The  problems  of  tool  integration  with  CM 
capabilities  must  be  addressed.  Better  CM  process  definition  and  implementation  of 
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processes  are  required.  More  support  for  management  in  decisions  about  CM  systems,  such 
as  the  buy  versus  build  decision,  and  in  evaluating  CM  systems  is  crucial.  Reference  models 
for  environments  are  being  standardized,  as  are  the  CM  services  involved  with  them.  Govern¬ 
mental  contracts  will  eventually  require  contractors  to  have  a  certain  level  of  CM  support  in 
their  environment,  so  the  ramifications  of  this  requirement  need  to  be  addressed. 

As  CM  is  examined  more  closely  in  relation  to  software  engineering  in  toto,  several  questions 
emerge,  with  the  most  interesting  technical  one  asking  “What  part  of  the  software  engineering 
problem  is  CM?"  It  is  not  clear  whether  general  software  engineering  issues,  such  as  team 
support,  process  support,  and  tool  integration  are  areas  that  are  part  of  CM,  yet  CM  vendors 
generally  need  to  address  these  issues  when  giving  the  customer  an  off-the-shelf  solution. 
This  question  also  arises  under  the  guise  of  “Where  do  we  put  CM?"  when  committees  are 
trying  to  decide  upon  the  architecture  for  their  environment  framework  reference  models. 

At  the  moment,  a  long-term  CM  solution  that  supports  long-lived,  changing  software  for  large 
organizations  with  diverse  software  applications  will  not  be  found  in  a  single  CM  tool,  nor  in  a 
single  environment.  Other  aspects  of  software  engineering  need  to  be  addressed  in  unison, 
such  as  process  modelling,  software  architectures,  team  support,  and  tool  integration.  CM  has 
an  impact  on  these  aspects  and  vice  versa.  Thus,  CM  is  a  keystone  to  the  software  engineer¬ 
ing  problem  and  should  not  be  viewed  in  isolation  from  other  software  engineering  problems 
and  solutions.  Good  CM  support  in  an  environment  will  greatly  enhance  its  usability,  whereas 
inadequate  CM  support  makes  an  environment  useless. 
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3  State  of  Environment  Technology 
in  the  SDE  Community 

An  SDE  is  an  environment  that  assists  software  engineers  in  developing  and  maintaining  soft¬ 
ware.  There  has  been,  and  continues  to  be.  a  lot  of  work  on  environments  in  the  SDE  commu¬ 
nity.  The  book  on  SDEs  edited  by  Long  [Long  911  and  the  symposium  proceedings  of  ACM 
SIGSOFT/SIGPLAN  [Henderson  88]  provide  examples  of  work  being  done.  Two  major  areas 
of  concern  are  tool  integration  for  third-party  CASE  tools,  and  software  process  modelling  for 
describing  and  automating  the  steps  involved  in  developing  software.  International  conferenc¬ 
es  and  workshops  are  devoted  to  these  topics  [Dowson  91],  [Fuggetta  91]. 

One  way  to  begin  examining  environment  technology  is  by  categorization  of  environments,  as 
done  by  Dart,  Ellison,  Feiler  and  Habermann,  which  suggests  that  SDEs,  from  a  user’s  per¬ 
spective,  fall  into  four  categories:  language-centered,  structure-oriented,  toolkit,  and  method- 
based  environments  [Dart  87].  Other  categorizations  have  been  published  presenting  varying 
perspectives  [Perry  91],  [Penedo  88].  The  various  categorizations  show  that  different  criteria 
can  be  chosen  for  categorizing  and  that  environments  generally  don’t  fit  exactly  into  one  cat¬ 
egory. 

A  major  concern  these  days  is  that  of  tool  integration:  what  it  means  and  how  the  notion  of 
“openness”  for  third-party  tool  integration  can  be  supported.  The  paper  on  tool  integration 
technologies  by  Brown,  Feiler  and  Wallnau  [Brown  91]  divides  the  tool  integration  solution  into 
Integrated  project  support  environments  (IPSEs)  such  as  those  based  on  the  international 
standard,  the  portable  common  tool  environment  (PCTE)  [Boudier  88],  and  into  tool 
coalitions  that  are  based  on  vendor-supplied  tool  integration  facilities  at  the  source  code  lev¬ 
el.  PCTE  is  a  set  of  standardized,  public  tool  interfaces  to  basic  environment  mechanisms 
which  support  a  common  interface  to  a  set  of  cooperating,  data  sharing  tools.  It  is  intended  to 
be  a  solution  to  a  variety  of  integration  and  portability  problems  encountered  when  running 
multiple  tools  from  multiple  vendors  on  multiple  platforms.  PCTE  essentially  provides  a  cen¬ 
tralized  database  of  schemas.  The  IPSEs  are  intended  to  provide  an  all  encompassing  infra¬ 
structure  that  enables  tool  integration  and  provides  features  for  life-cycle  activities  (such  as 
specification,  design,  and  coding)  and  cross-life-cycle  activities  (such  as  configuration  man¬ 
agement,  project  management,  and  documentation  production).  The  CASE  coalitions  provide 
a  piecemeal,  esoteric  solution  where  vendors  sign  a  pact  and  integrate  their  tools  to  form  a 
tightly  coupled  set  of  tools  to  suit  particular  life-cycle  activities,  such  as  design  and  coding. 
Overall,  the  IPSE  and  the  tool  coalition  approaches  provide  benefits  but  require  tradeoffs. 

Another  approach  to  the  tool  integration  problem  is  to  try  to  avoid  it  by  providing  engineers  with 
a  meta-tool,  a  tool  that  enables  them  to  rapidly  develop  their  own,  highly  customized  set  of 
CASE  tools.  (Examples  include  the  Virtual  Software  Factory  [Bloor  90]  and  the  Tool  Builder’s 
Kit  [Alderson  91  ].)  These  serve  as  a  repository  for  the  logical  model  of  the  environment  as  well 
as  for  some  elements  of  the  physical  implementation.  The  tools  are  developed  using  the  pro- 
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vided  formalism  and  run  under  the  provided  runtime  environment  and  with  the  user-defined 
process  model. 

For  process  modelling,  the  design  of  formalisms  for  describing  processes  and  the  develop¬ 
ment  of  mechanisms  for  implementing  them  are  active  research  topics.  Environments  built  on 
top  of  PCTE,  such  as  the  EAST,  Entreprise  II  and  ALF  environments  [Oquendo  90]  try  to  pro¬ 
vide  flexible  process  modelling  capabilities,  but  must  address  difficulties  such  as  the  need  for 
common  services  (for  compiex  object  passing  and  sharing)  and  active  mechanisms  (for  noti¬ 
fication  and  triggers). 

At  the  SEI,  we  are  bringing  together  terminology  and  concepts  that  assist  in  understanding  the 
issues  for  tool  integration  and  process  modelling  which  can  he  incorporated  into  an  environ¬ 
ment  framework  [Brown  91]. 
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4  State  of  Automated  CM  in  the  CAD  Community 


Katz  gives  an  overview  of  the  basic  versioning  capabiiities  for  CAD  frameworks  in  which  he 
distinguishes  between  seven  ciasses  of  mechanisms  [Katz  90].  These  include: 

1 .  Organization  of  space  of  versions:  represents  a  repository  with  a  version 
tree  of  objects. 

2.  Dynamic  configurations  and  dereferencing:  refer  to  static  and  dynamic 
binding  of  versions  to  configurations  and  consistency  checking. 

3.  Hierarchical  compositions  across  versions:  determine  the  structure  and 
composition  of  configurations. 

4.  Alternative  groupings  of  versions:  refer  to  partitioning  of  a  system  and 
regrouping  of  objects  based  on  certain  properties. 

5.  Distinctions  of  instances  versus  definitions:  make  a  clear  distinction 
between  the  instance  and  definition  of  an  object  and  that  relationship. 

6.  Change  notification  and  propagation:  relate  to  time-based  notification  and 
acknowledgment  of  events,  and  propagation  of  changes. 

7.  Workspace  organization:  provides  a  means  for  multiple  designers  to  share 
objects  and  ways  of  providing  muitiple  repositories  (private,  group/project, 
and  public/archive). 

Katz  concludes  that  the  versioning  technology  for  the  CAD  community  has  variations  on  a 
theme:  many  of  the  mechanisms  are  similar.  Thus,  there  is  a  need  for  a  unified  model  of  mech¬ 
anisms  and  a  unified  terminology.  But  the  real  challenge  of  the  future  is  to  create  a  single,  tai- 
lorable  framework  for  CAD  encompassing  all  of  the  versioning  capabilities  above.  Perhaps  the 
work  of  the  CFI  will  address  this  challenge. 

From  a  software  engineering  perspective,  it  appears  that,  in  general,  commercial  CAD  frame¬ 
works  generally  offer  a  version  control  facility  along  with  a  notification  facility.  Most  of  the  other 
classes  of  mechanisms  tend  to  be  in  research  CAD  frameworks  and  fall  into  the  database  re¬ 
search  arena.  The  CM  problems  evolve  around  the  need  to  deal  with  the  existence  of  multiple 
versions  of  chips  that  are  to  be  used  in  different  chip  configurations  as  well  as  "competitive 
tools",  i.e.,  allowing  for  the  coexistence  of  multiple  versions  of  tools  where  any  version  can  be 
used  at  any  time. 
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5  State  of  Environment  Technology 
in  the  CAD  Community 

A  CAD  framework  is  an  environment  that  assists  hardware  engineers  in  designing,  drawing 
and  simulating  circuits.  It  is  intended  to  provide  a  broad  spectrum  of  services  relating  to  data, 
task,  process  and  methodology  management  (Harrison  90].  There  is  a  significant  amount  of 
work  on  environments  in  the  CAD  community.  The  book  on  electronic  design  frameworks  by 
Rammig  and  Waxman  provides  examples  of  tool  integration  strategies  and  frameworks  [Ram- 
mig  91],  and  the  proceedings  of  the  Design  Automation  Conference  provides  a  wide  range  of 
issues  in  the  CAD  community  [ACM  91].  When  examining  CAD  frameworks,  it  appears  that 
CAD  framework  vendors  sell  two  kinds  of  products.  One  is  a  tool  framework  that  encompasses 
tightly  integrated  tool  sets  with  inter-tool  communication,  a  common  representational  data¬ 
base,  and  version  control;  these  optimize  the  performance  of  combinations  of  vendor's  prod¬ 
ucts  via  source  code  integration.  The  second  is  a  design-management  framework  that  assists 
in  the  process  of  designing  ana  testing  circuits  by  providing  data  management  capabilities 
such  as  CM,  data  flow,  and  event  triggers;  tool  run  management  for  sequencing  and  executing 
tools;  and  tool  encapsulation  for  enabling  an  “open”  architecture  for  integrating  third-party 
tools. 

The  goal  of  the  CFI  efforts  is  to  provide  a  standardized  framework  for  CAD  tools  that  serves 
as  a  general,  common  software  infrastructure  for  efficiently  building,  maintaining  and  config¬ 
uring  open,  integrated  CAD  environments.  This  involves  developing  guidelines  for  enabling 
cooperation  of  CAD  tools.  Such  work  is  progressing  within  the  CFI. 
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6  Comparisons  Between  the  Communities 


There  are  many  similarities  in  the  technological  solutions  that  each  community  uses,  and 
some  differences  Uiat  make  for  varying  levels  of  complexity  in  the  solutions. 


Similarities  in  Concepts  and  Technology 

It  is  clear  that  both  communities  would  like  a  common  terminology  for  CM  concepts.  CM  mech¬ 
anisms  appear  very  similar,  and  many  are  variations  on  a  theme.  For  tool  integration,  the  need 
for  a  standard  framework  is  common  to  both  communities,  as  are  the  natures  of  the  problems 
and  solutions.  The  challenges  of  the  future — ^tool  integration,  data  management,  process  im¬ 
plementation,  and  managing  multiple  methodologies — appear  the  same  for  both  communities. 
From  a  software  engineering  perspective,  the  CFI  work  attempts  to  define  an  infrastructure 
that  is  similar  to  many  efforts  in  the  SDE  community  for  defining  reference  models  for  IPSEs. 


Figure  6-1  Sequence  of  Events  In  Understanding  Concepts 

Scanning  the  literature  published  in  the  SDE  and  CAD  communities  shows  that  the  work  on 
environments  and  CM  is  progressing  in  a  similar  fashion.  Figure  6-1  shows  a  simplified  and 
generalized  view  of  the  process  of  the  evolution  towards  an  understanding  of  the  concepts  and 
mechanisms.  Researchers  experiment  with  ideas  and  create  prototype  systems.  Commercial 
vendors  create  production-quality  tools,  sometimes  using  research  ideas  but  scaling  them  up 
to  industrial  strength,  and  sometimes  coming  up  with  innovative  mechanisms.  Surveying  all 
the  research  and  commercial  systems  gleans  a  plethora  of  mechanisms  used.  Technology  an¬ 
alysts  then  start  to  extract  concepts  from  the  mechanisms  and  begin  to  classify  them  and  de¬ 
velop  a  vocabulary  enabling  engineers  to  discuss  the  technology.  From  here  begins  the  work 
of  standardization  of  mechanisms,  concepts  and  frameworks,  along  with  the  definition  of 
classes  of  services  that  provide  certain  functionality.  Also,  different  groups  tend  to  realize  that 
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there  are  similarities  in  efforts,  and  will  combine  forces  to  consolidate  work  efforts.  This  hap¬ 
pens  in  cycles,  for  each  new  round  of  technology. 

A  good  example  is  with  CM  in  the  SDE  community,  in  the  past,  most  CM  systems  were  home¬ 
grown,  that  is,  built  in-house  by  the  organization  since  it  was  impossible  to  buy  a  CM  system. 
Researchers  started  experimenting  with  developing  third-party  tools,  and  start-up  companies 
began  to  develop  them  from  their  experience  in  industry  and  from  research.  Today  we  have  a 
flourishing  CM  tool  industry  with  many  tools  and  environments  providing  CM  capabilities.  As 
customers  and  industry  analysts  attempt  to  evaluate  all  these  tools  and  understand  the  many 
mechanisms  available,  it  is  necessary  to  find  a  means  for  understanding  such.  Places  such  as 
the  SEt  examine  technology  and  extract  the  concepts  and  classify  the  tools  which  helps  the 
customers  understand  the  state  of  the  technology.  Upon  further  examination  of  the  plethora  of 
tools  many  similarities  are  seen.  As  industry  sees  trends  of  variations  on  themes,  it  becomes 
clear  that  consolidation  of  efforts  and  standardization  are  possible.  This  then  evolves  into  a 
standardization  of  common  CM  services,  which  is  beginning  today. 

The  SDE  community  is  at  the  level  of  standardization,  definition  of  services,  and  consolidation 
of  efforts  for  tool  integration  (with  PCTE  at  least)  and  CM.  It  appears  that  the  CAD  community 
is  also  at  this  level  with  its  CFI  efforts. 

Differences  Between  the  Communities 

The  communities  appear  to  differ  on  the  degree  of  domain  specificity  that  they  are  dealing 
with.  The  differences  relate  to  how  well  we  understand  objects,  how  objects  are  used,  the  way 
objects  are  created,  the  breadth  of  the  problem  domain,  the  complexity  of  transformations,  and 
the  understanding  of  the  design  process.  These  are  highlighted  in  Figure  6-2: 


CAD  Community 

SDE  Community 

Known  objects  (pin,  unit,  etc.) 

Unknown  objects  (file,  procedure,  etc.) 

Uses  reusable  objects 

Builds  new  objects 

Many  views  (layout,  etc.) 

Many  instances  (compilation,  etc.) 

Domain  specific 

Operating-system  based 

Many  tool  transformations 

Compiler-based  transformations 

Known  design  process 

Ad  hoc  design  process 

Figure  6-2  Differences  Between  CAD  and  SDE  Notions 

In  the  CAD  community,  engineers  deal  with  known  objects,  objects  that  have  some  semantics 
associated  with  them  such  as  pins  or  logic  units.  To  create  new  objects,  engineers  can  reuse 
existing  parts  of  chip  designs.  For  a  description  of  an  object,  many  different  views  (such  as 
netlist  and  logic  schemata)  can  be  seen.  CAD  environments  are  specifically  suited  to  the  do¬ 
main  of  hardware  design  and  therefore  the  hardware  designer.  There  are  many  tools  in  a  CAD 
framework  that  transform  a  description  into  a  different  view.  Thus,  a  CAD  framework  is  multi- 
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tool  oriented.  The  CAD  community  uses  the  standard  language  VHDL  as  a  formalism  for  de¬ 
scribing  hardware  designs.  The  design  process  of  creating  an  integrated  circuit  is  fairly  well 
understood,  and  the  cost  and  time  for  developing  a  particular  version  is  known.  There  are 
many  tools  that  aid  the  design  process  in  ways  such  as  analyzing  and  simulating  the  circuit. 

in  the  SDE  community,  the  lowest  granularity  of  a  well  understood  object  is  that  of  a  file  or  pro¬ 
cedure,  and  there  generally  are  no  real  semantics  associated  with  these.  To  create  new  ob¬ 
jects,  programmers  tend  to  create  new  code  by  editing  and  compiling  rather  than  reusing 
existing  code,  thus  creating  instances  of  object  code.  SDEs  are  based  on  a  specific  operating 
system  in  most  cases  and  are  intended  to  be  fairly  generic  and  suited  to  any  kind  of  software 
engineer  in  any  domain.  Most  of  the  transformations  done  are  carried  out  via  the  compiler 
since  SDE’s  are  very  single  tool  oriented,  and  that  tool  is  the  compiler.  No  single,  standard  pro¬ 
gramming/design  language  exists  for  software  engineers  to  describe  their  applications.  The 
software  design  process  is  still  an  ad-hoc  one  and  very  few  tools  exist  to  aid  the  designer  in 
going  from  one  level  of  abstraction  to  the  next. 

While  differences  can  be  found  between  the  ways  the  CAD  and  SDE  communities  do  their 
work  and  the  kinds  of  tools  that  are  available  to  them,  the  biggest  gap  is  really  that  neither  com¬ 
munity  seems  to  be  aware  of  what  the  other  is  doing.  (Obviously  this  is  a  generalization  since 
some  people  do  span  the  gap.)  The  future  looks  promising  though,  since  several  hardware- 
software  workshops  are  being  held  and  various  groups  such  as  the  architecture  group  of  the 
CFI  and  a  PCTE  group  are  willing  to  look  closely  and  seriously  at  the  similarities  and  differenc¬ 
es  between  the  communities.  For  the  SEl,  we  are  interested  in  finding  'ihe  best  practice”  so 
that  we  can  help  Improve  the  state  of  the  practice.  To  find  the  best  practice,  It  is  necessary  to 
be  involved  with  as  many  communities  as  possible. 
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7  Conclusion 


SOE  and  CAD  CM  technology  have  a  large  degree  of  overlap.  In  both  communities,  there  is  a 
need  for  a  unified  CM  model  to  assist  in  defining  a  CM  vocabulary  as  well  as  a  CM  functionality 
within  the  frameworks.  There  is  a  possibility  that  defining  unified  CM  services  across  hardware 
and  software  frameworks  would  have  the  benefit  of  common  terminology,  at  least  in  the  CM 
arena,  and  would  thus  aid  progress.  It  would  be  beneficial  to  avoid  duplication  of  effort. 

From  a  software  engineering  viewpoint,  CAD  and  SDE  environments  are  progressing  in  simi¬ 
lar  directions.  Both  are  tackling  the  third-party  tool  integration  problem  either  via  the  same 
mechanisms,  or  by  consensus  through  common  models  and  interfaces.  Research  is  continu¬ 
ing  on  understanding  process  models  and  implementing  them.  The  CAD  frameworks  are  in¬ 
tended  to  suit  the  particuiar  domain  of  developing  integrated  circuits.  SDE  frameworks  are 
intended  to  suit  all  of  the  software  engineering  community.  Domain  specificity  should  enable 
faster  progress. 

What  can  be  learned  by  the  software  engineering  community  from  the  CAD  efforts?  One  an¬ 
swer  concerns  the  user  interface  model  and  the  design  process.  CAD  frameworks  present  a 
more  intuitively  obvious  user  interface  that  takes  into  account  the  domain  of  the  user  through 
use  of  graphics,  and  by  hiding  as  much  of  the  underlying  implementation  of  the  tools  as  pos¬ 
sible.  Also,  they  provide  automated  support  for  the  design  process  such  as  tools  that  help  take 
a  chip  design  from  one  level  of  abstraction  to  the  next  via  analyzing,  synthesizing  and  simu¬ 
lating. 

What  can  be  learned  by  the  CAD  community  from  SDE  work?  One  answer  is  teamwork,  multi¬ 
user  support,  and  data  modelling  in  the  sense  of  consistency  analysis.  SDEs  provide  mecha¬ 
nisms  to  allow  multiple  users  to  work  in  a  synchronized  and  coordinated  manner  on  the  same 
or  parallel  pieces  of  code,  such  as  with  transactions.  Also,  mechanisms  are  provided  for  de¬ 
scribing  the  structure  and  characteristics  of  data  and  for  identifying  and  maintaining  consisten¬ 
cy  between  the  data,  such  as  checking  for  version  skews  and  compatibility  between  source 
code  interfaces  and  bodies. 

It  would  be  beneficial  for  each  community  to  be  aware  of  each  other’s  work.  There  are  many- 
fold  advantages  to  broadening  the  concepts  and  mechanisms  of  each  community.  Perhaps  it 
is  possible  that  a  unified  framework  suiting  SDE  and  CAD  needs  could  become  a  reality  one 
day.  Such  a  framework  would  offer  the  best  of  both  worlds.  The  communities  can  cooperate 
by  reading  each  other’s  papers  and  attending  each  other’s  conferences  and  workshops. 

There  are  many  problems  confronting  SDEs.  No  doubt  the  CAD  community  is,  or  will  have  to 
confront  these  problems  too.  Thus,  any  joint  efforts  will  be  the  first  steps  towards  cross  fertili¬ 
zation  of  ideas.  The  future  problems  confronting  SDEs  relate  to  technology  (such  as  address¬ 
ing  new  CM  requirements),  process  (such  as  better  process  guidance  and  tailoring), 
standardization  (such  as  for  CM  services),  and  management  (such  as  commitment  of  resourc¬ 
es  and  assistance  in  helping  management  make  the  ”buy  vs.  build”  decision).  In  particular,  the 
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technological  problems  concern  interoperability  between  third-party  CM  tools,  better  support 
for  large  software  changes  enabling  a  global  perspective  on  CM  repositories,  tailoring  CM 
tools,  distributed  CM  support,  and  framework  infrastructures  such  as  PCTE  and  object  man¬ 
agement  systems.  At  the  SEI,  we  are  developing  a  CM  services  model  to  suit  the  future  re¬ 
quirements  of  SDEs,  particularly  frameworks  based  on  the  client/server  model  technology. 
Our  aim  is  to  ensure  that  the  CM  services  model  is  equally  applicable  to  the  CAD  community. 
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